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METHOD AND SYSTEM FOR USING WITH CONFIDENCE 
CERTIFICATES ISSUED FROM CERTIFICATE AUTHORITIES 



Technical field 



The present invention relates to the security of 
5 communications between computer devices, and more particularly 
to a method and system for using, with confidence and trust, 
certificates issued from Certificate Authorities (CA) . 

Background art 



Security 

10 Among the multiple computing and networking security issues, 
one important cause of concern relates to the identity of 
communicating entities. When a user communicates with a remote 
entity (for instance another user or any computer), it is very 
important to be confident of the identity of the remote 

15 entity* For instance, a user who wishes to send confidential 
information related to his credit card to a particular bank, 
wants to be sure that such critical information will not be 
sent to someone else pretending to be his bank. Most current 
methods for certifying an identity of an entity (such as a 

20 user, a company, a computer device) are based on 
"Certificates". 



Level of Trust 

How secure a certifying method is, depends on the degree of 
"confidence" or "trust" that the user can associate with the 
25 Certificate he is using. Fundamentally, this degree of 
confidence depends on whether the public key element of the 
Certificate the user is using is really "owned" by the entity 
(e.g. user) defined in the "Subject Name" field of the 
certificate . 
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User Certificates are signed by a third party called 
Certificate Authority (CA) which attests that the public key 
belongs to the user. A Certificate verification process checks 
that the Certificate has been actually signed by the CA. This 
process therefore relies on the user who has obtained the CA 
Certificate in order to retrieve the CA public key. Frequently 
CA Certificates are issued in the form of a self-signed 
Certificate. A self-signed CA Certificate cannot be directly 
trusted because it is signed with the public key of the CA and 
is not signed by another trusted CA. The CA' s public key is 
signed using the corresponding CA private key. While this 
process ensures the integrity of a Certificate, it does not 
provide any protection concerning its authentication. Any 
entity can generate a key pair and create a self-signed 
certificate that can pretend to be, for instance, a Verisign 
CA Certificate. Therefore, the user needs to trust the CA 
Certificate and to be sure that the CA Certificate is issued 
from a known source. 

In some situations, the user wants to communicate with another 
entity that has a Certificate issued by a CA that he doesn't 
know and that is different from his own issuing CA. In such a 
situation, the user must retrieve the Certificate of the CA 
that has issued the Certificate of the entity. There are three 
main techniques, with various degrees of confidence as 
explained below: 

• Known Web Site. This is the weakest method. The user 
downloads the CA trusted Certificate from a known web site. 
Then, the user can load the trusted Certificate into the 
appropriate trusted certificate database. The vulnerability 
of this method is the following : the web site can be either 
spoofed or hacked and a false CA Certificate can be 
substituted to the right one. The user is then liable to 
attacks when he receives false user Certificates. 
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Embedded Certificates, This technique is prevalent for web 
Browsers. Most web Browsers are pre-loaded with trusted 
public keys/Certificates, for instance Verisign CA 
Certificates. This technique is more secure than the Known 
Web Site technique. However, the user depends on a CA 
prescribed by the web Browser. This technique is well 
adapted to "personal" users, however it lacks flexibility 
for tradespeople or enterprises. For instance, the user is 
obliged to support the CA prescribed by the web Browser and 
also to support its topology. Furthermore, if the CA' s 
private key is compromised (has been discovered for 
instance) , it will be necessary to load a new CA trusted 
Certificate. Some enterprises wish to have the CA under 
their administrative control - which is clearly not the case 
in this situation. 



Secure Delivery. This method is the more secure and it 
provides some form of flexibility. In this case, the CA 
Certificate (or just the public key) is provided to the user 
through an alternate secure channel. This alternate secure 
20 channel is for instance a physical mail or an electronic 

mail via a specially encrypted communications channel. 
However, this method is generally complex to implement. 



In most common situations, when a user retrieves a new CA 
Certificate during a communication with another entity (for 

25 instance another user) , he must specify whether or not he 
accepts this new CA Certificate. Generally, the user accepts 
the new CA Certificate, without really knowing if he can trust 
it, simply because he wants to continue the communication. 
This is an open hole in the security, because this CA may be 

50 malicious and may attack the user's security. 

The problem is then to trust a CA Certificate, and to ensure 
that a user cannot use a CA Certificate he cannot trust. 
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Certificate 

A Certificate is a structure that contains a public value 
(i.e. a public key) associated with an identity. For instance, 
within a X.509 Certificate, the public key is bound to a 
5 "user' s name" (a "user's name" can be for instance the name of 
a physical person or can be the name of any device or computer 
which has an identity) . A third party (a Certificate 
Authority) attests that the public key belongs to the user. A 
X.509 Certificate is a very formal structure that comprises 
10 different elements: 

(101) Subject; This is the "user's name" {the Subject can 
be any identity value) . 

(102) Issuer; This is the name of the third party that has 
issued/generated the Certificate. This third party is the 

15 Certificate Authority (CA) . 

(103) Public Key Value; This is the public key of a 
public/private key pair. An associated field defines the 
public key algorithm that must be used, for instance a RSA , 
Dif f ie-Hellman or DSA public key. 

20 • (104) Validity: Two fields are used to define the period of 
validity (valid from date 1 and valid to date 2) . 

(105) Serial Number: This field provides a unique 
Certificate serial number for the issuer. 

(106) Signature: The signature is an encrypted digest 
25 generated by the Certificate Authority (CA) for 

authenticating the whole Certificate.- The digest results 
from the hashing of the Certificate. The digest is encrypted 
using the CA private key. The encrypted digest which is the 
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signature, "certifies" that the Subject is the 
the public and private keys. 



'owner' 



of 



Certificate Verification 

The Certificate needs to be verified to ensure that it is 
valid. This is a quite complex process. The verification by an 
end user of a Certificate comprises the checking of the 
following elements : 



• Valid (or any) Subject and Issuer names are defined in 
the Certificate. 

10 • The Certificate is not expired (checking of the Validity 

period field) . 

• The Certificate has not been revoked (this may be 
determined by obtaining a current Certificate Revocation 
List from the CA) . 

15 • The signature on the Certificate is valid (the signature 

is not verified by using the Certificate's public key but 
by using the CA public key) . 

The method for validating the signature is quite simple, and 
comprises the steps of: 

20 • extracting the issuer's name (CA name) from the 

Certificate; 

• locating the issuer's Certificate (CA Certificate) or the 
issuer's public key (CA public key). 

• checking that the end user's Certificate signature was 
25 generated by the issuer (CA) using the issuer's public 

key (CA public key) . 

Certificates are generated by a Certificate Authority (CA) . 
Two main methods can be used: 



• Centralized Generation: The private/public key pair is 
0 generated by the end user (defined in the subject field of 
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the Certificate) • The public key is directly provided by the 
end user to the CA software to create a Certificate, The 
Certificate can be provided to another end user via any 
suitable channel. The channel does not have to be secure 
5 because a Certificate is a self protecting structure (given 

the CA' s signature). 

D± s fcjriJbu te<d Generation: The private/public key pair is 
generated by the end user. The end user requests the CA to 
build a Certificate including the end user public key. The 
10 public key is then sent to the CA for certification. If the 

request is valid then the CA returns a Certificate 
associating the user identity with the user public key to 
the end user. 

Of course these two methods can be combined in any system, 
15 because trusted CA keys are generated by the Certificate 
Authority (CA) . 

Centralized Generation of Certificate 

Different techniques that can be used: 

• Manual Distribution: In this case the user is registered on 
20 the CA (or associated Registration Authority) by an 

administrator. According to the enterprise's security 
policy, the user can declare himself and request a 
Certificate to the administrator of the CA. The process of 
registering the user may include the creation of a token. 
25 The token contains the user' s Certificate and the associated 

private key. The token is physically supplied to the user. 
The token can take the form of a disk file or a smart card. 
For more security, a security PIN code can be used to 
''unlock" the token. If a PIN system is implemented then it 
30 is then possible to mail the token to the user - physically 

or even electronically. However, the PIN should always be 
sent to the user by means of a separate secure physical 
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method. Once the user has received the Certificate, he can 
use its public key to provide security services. This 
technique does not require a permanent connection between 
the users and the Certificate Authority (CA) . 



5 • Request: Typically, to request a Certificate (or in 
Verisign' s parlance a Digital ID) , the user uses a web 
Browser to have access to a CA' s web page. The user is 
invited to enter some personal information, primarily for 
identification purposes. The user is also invited to enter 

10 some form of Password. After having requested the 

Certificate (and also triggered the central generation of 
the public/private key pair) , the user typically receives an 
e-mail with details on the way to fetch the Certificate. 
Generally this e-mail contains the URL (Uniform Resource 

15 Locator) of a web page that the user must visit to fetch the 

Certificate. When the user visits the web site, he is 
invited to enter the Password (or something derived from 
it) . The Certificate is then sent to the user using a HTTP 
(Hypertext Transfer Protocol) message that the Web Browser 
20 can recognise and can enter in its Certificate database. The 

user must also receive the CA' s Trusted Public Key. Most 
Browsers are already installed with some trusted public 
keys, for instance Versigns. If the CA' s trusted public key 
is not installed within the web Browser then a similar 
25 operation can be used to fetch it. 

• Request - with authentication: This technique is very 
similar to the previous one (Request) . In an additional 
step, authentication checks are made. Typically, off-line 
security checks are performed on some requester's personal 
30 information. This technique is particularly adapted to 

commercial communications where a higher level of confidence 
in the Certificate is required. 
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Distributed Generation of Certificate 

In this method, the key material is generated by the user and 
the public key is sent to the CA for signature and for 
creation of the Certificate. A standalone public key is 
5 vulnerable to tampering because no identity is securely 
associated with it* Therefore some techniques are designed to 
protect the public key in the transmission from the user to 
the CA. 



Summary of the invention 



10 The present invention relates to the security of 
communications between computer devices, and more particularly 
to a method and system for using, with confidence and trust, 
certificates issued from Certificate Authorities (CA) . 



The present invention discloses a system and method in a 
15 workstation connected to a network, for filtering certificates 
issued from one or a plurality certificate authorities (CA) . 
The method comprises the steps of: 



• receiving a certificate and storing said certificate; 

• preventing the use of said certificate until validation; 

20 • identifying the certificate authority (CA) that has issued 
the certificate; 

• verifying whether or not said identified certificate 
authority (CA) is a trusted certificate authority, said step 
comprising the further steps of: 

25 • identifying one or a plurality of certificate authority 

filters (CAF) referring to a table (CFC table) , said 
table comprising an identification of one or a plurality 
of certifcate authority filters ; 
• sending a request to one or a plurality of said 

30 identified certificate authority filters; 
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• receiving from each certificate authority filter a 
response to said request, said response comprising 
information related to the certificate authority that has 
issued the certificate and depending on said information 
a public key; 

• determining according to said responses whether or not 
said certificate authority is a trusted certificate 
authority; 

validating the certificate if the certificate authority (CA) 
that has issued the the certificate is a trusted certificate 
authority. 



The present invention also discloses a system and method in a 
certificate authority filter connected to a network, for 
filtering certificates issued from one or a plurality 
15 certificate authorities (CA) . The method comprises the steps 
of: 

• receiving a request comprising an identification of a 
certificate authority (CA) ; 

• identifying the certificate authority (CA) in said request; 
20 • identifying in a table (CAF table) the certificate authority 

identified in the request, said table comprising: 

• the identification of one or a plurality of certificate 
authorities; and 

• a level of trust and a public key associated with each of 
25 said one or plurality of certificate authorities; 

• determining the level of trust of the identified certificate 
authority (CA) referring to said table; 

• retrieving the public key associated with the identified 
certificate authority (CA) refering to said table; 

30 • sending a response to the originator of the request, said 
response comprising the level of trust of the certificate 
authority identified in the request and the public key 
associated with said certificate authority. 
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Further embodiments of the invention are provided in the 
appended dependent claims. 

Brief description of the drawings 

The novel and inventive features believed characteristics of 
5 the invention are set forth in the appended claims. The 
invention itself, however, as well as a preferred mode of use, 
further objects and advantages thereof, will best be 
understood by reference to the following detailed description 
of an illustrative detailed embodiment when read in 
10 conjunction with the accompanying drawings, wherein : 

Figure 1 describes the structure of a Certificate, 
according to prior art. 

Figure 2 shows the use of Certificates between two 
entities, according to prior art. 

Figure 3 describes the different entities involved in the 
present invention. 

Figure 4 describes the internal logic of the Certificate 
Checker according to the present invention. 
Figure 5 describes the CA Filter Table according to the 
present invention . 

Figure 6 describes the Certificate Checker Table 
according to the present invention. 

Figure 7 describes the internal logic of the CA Filter 
according to the present invention. 

25 Preferred embodiment of the invention 

Introduction 

Figure 2 shows the use of Certificates between two entities, 
according to prior art. When the Entity A (201) (for instance 
a user or any computer device) wants to send a message to the 
30 Entity B (202) , the following steps occur: 



15 



20 
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• The Entity A (201) retrieves (204) a Certificate (with 
Entity A as "Subject") from its Cerfificate Authority (CA) 
(203) . The CA is the "issuer" of this Certificate* The 
Certificate is used by the Entity B to authenticate messages 

5 sent by Entity A. The Certificate can be retrieved by Entity 

B from the CA or sent by Entity A. 

• The Entity A locally stores the retrieved Certificate. The 
private key associated with this Certificate will be used to 
sign all messages that will be sent later. 

10 • The Entity A (201) sends (205) a message to Entity B (202) 
along with the retrieved Certificate if Entity B has not 
already retrieved the Certificate from the CA. 

• The Entity B (202) receives (205) the signed message from 
Entity A. 

15 • The Entity B identifies the CA that has issued the received 
Certificate (203), using the Issuer (102) field of the 
Certificate . 

• If the Entity B does not have locally the Certificate of the 
CA (for instance stored in a local cache) , it retrieves 

20 (206) this CA Certificate from the CA. 

• The Entity B then authenticates the Entity A (Entity B makes 
sure of the identity of Entity A) using: 

• The Certificate received either from Entity A with the 
message or separately from the CA; 
25 • The CA Certificate. 



Trusting CA Certificates 

Figure 3 describes the different entities involved in the 
method and system disclosed in the present invention. 



Entity A 

50 The Entity A (301) (for instance any user or computer device) 
wants to communicate with the Entity B (302) . For instance, 
Entity A is an external user and Entity B is a user within a 
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company network ♦ When Entity A sends (303) a message signed 
with a Certificate to Entity B, this signed message is first 
received by a Certificate Locker component (311) within Entity 
B (302) . 

Certificate Locker and Certificate Checker 

Both are working together and the Certificate Checker can be 
considered as a subset of the Certificate Locker. The main 
purpose of the Certificate Locker (311) is to: 

• store the Certificate in a "frozen zone" for preventing any 
application from using it, A "frozen zone" (which can also 
be called "protected zone") can be the quarantine area of 
the antivirus checker or of a dedicated application having 
the same function. 

Then the Certificate Locker calls the Certificate Checker 
(312) to: 

• identify the Certificate Authority (CA) that has issued the 
Certificate . 

• verify whether or not the identified CA is a trusted CA. For 
that, the Certificate Filter accesses one or a plurality of 
CA Filters (309) using the information contained in a 
Certificate Filter (CFC Table) Table (313). 

• if the Certificate Authority is a trusted CA, the CA public 
key or self-signed Certificate is sent back to the 
workstation in order to authenticate the Certificate. 

Depending on the Certificate Authority is a trusted CA or not, 
the Certificate Checker (312) informs the Certificate Locker 
(311) to: 

• delete the certificate if the Certificate Authority is not a 
trusted CA. 
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let the Certificate in the "frozen zone" if the CA is not 
yet approved. 

retrieve the certificate from the "frozen zone" when the 
Certificate Authority that has issued this certificate, is a 
trusted CA. In this case, the Certificate Checker verifies 
the certificate signature using the public key transmitted 
by the device (308) comprising the CA filter (309) . 



Certificate Checker 

According to the present invention, the main purpose of the 
10 Certificate Checker (312) is to retrieve from one or a 
plurality of CA Filter a trusted Certificate for a particular 
CA. 



For each call of the Certificate Locker, the Certificate 
Checker performs the following operations: 



15 • retrieving the identifier of the Certificate Authority that 
has issued the received Certificate from the Issuer field 
of the received Certificate; 

• verifying the identity of the Certificate Authority; 

• if the Certificate Authority is a trusted CA, retrieving 
20 from one or a plurality of Certificate Authority Filters, a 

trusted Certificate . 



Typically, the Certificate Locker (311) and the Certificate 
Checker (312) are set up on a user workstation (302), or on 
any existing computer system adapted to provide the 
25 Certificate Locker and the Certificate Checker functions. 



Figure 4 is a flow chart which refers to the internal logic of 
the Certificate Checker. The Certificate Checker : 

• (401) : receives a request from the Certificate Locker. The 
Certificate Locker has received a signed message comprising 
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a message Certificate and this message Certificate has been 
stored in a "frozen zone". 

(402) : retrieves the name or the identification (called 
CA_Id) of the CA that has issued the received message 
Certificate, The Certificate Authority is identified using 
the "Issuer" field (102) of the message Certificate, 

(403) : retrieves a record (602) from the Certificate Checker 
Table (404) . The record comprises: 

• "CA_Filter_Id" : an identification of a Certificate 
Authority Filter (309). 

(405) : sends a request for a CA Certificate (or at least a 
CA public key) to the CA Filter identified by CA__Filter_Id. 
Said request for CA Certificate comprises: 

• The type of the request (called x> Request_Type" ) . This 
field is set to the value "Full" to request the CA 
Certificate (or at least the CA public key) in the 
response. Otherwise no CA Certificate will be returned 
in the response. 

• The CA identifier (called "CA_Identif ier") equal to 
CA_Id 

(4 06) receives the response to the request. Said response 
comprises the level of trust (called x 'Level_of__Trust") of 
the CA identified by CA_Id. 

Depending on the level of trust, the response also comprises 
the CA Certificate (or the CA public key) associated with 
the Certificate Authority. Since the "Request_Type" of the 
request was set to "Full", the CA Certificate is present in 
the response if the CA Filter found it. Otherwise no CA 
Certificate is returned in the response. 
(407) checks in the response: 

• the level of trust; 

• whether or not the CA certificate is received; and 

• whether or not the CA certificate is identical (the 
comparison is then OK) to the other CA certificates, if 
any, that have been previously retrieved from other CA 
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Filters. Said other CA certificates, if any, have been 
previously temporarily stored in (409) in the 
Certificate Checker Table. 

If the level of trust corresponds to the level of trust of a 
5 trusted CA and if the CA Certificate is identical to other 

CA Certificates (OK) : 

• (409) checks if there is another record (602) in the 
Certificate Checker Table (404) . 

• temporarily stores the received CA Certificate for a 
10 later comparison in step (407) if multiple CA Filters 

are defined in the Certificate Checker Table. 
If there is another record in the table: 

• (403) : retrieves the next record (602) from the 
Certificate Filter Table. 

15 If there is no other record in the table: 

• (410) : informs the Certificate Locker that the 
message Certificate can be retrieved from the 
"frozen zone" and be validated, 

• waits for the next request to process. 

20 If the level of trust does not correspond to the level of 

trust of a trusted CA or if the CA Certificate is not 
identical to other CA Certificates (KO) : 

• (408) informs the Certificate Locker to discards the 
received message Certificate stored in the "frozen 

25 zone" . 

• waits for the next request to process. 

In other words, three cases can be considered (the third one 
is optional) : 

1- If the level of trust assigned to the certificate . authority 
30 by each certificate authority filter (309) corresponds to the 
level of trust of a trusted Certificate Authority, 
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• compares the the CA certificates (or at least the 
public keys) received in the responses: 
if all the received CA certificates are identical, 

• (410) : informs the Certificate Locker that the 
5 message Certificate can be retrieved from the 

"frozen zone" and validated. 

• waits for the next request to process. 

if received CA certificates are not all identical, 

• (408) informs the Certificate Locker to discard the 
10 received message Certificate stored in the "frozen 

zone" . 

• waits for the next request to process. 

2. If the level of trust assigned to the certificate authority 
by at least one certificate authority filter (309) corresponds 
15 to the level of trust of an untrusted Certificate Authority, 

• (408) informs the Certificate Locker to discards the 
received message Certificate stored in the "frozen 
zone" . 

• waits for the next request to process. 

20 3. Optionally, if the level of trust assigned to the 
certificate authority by at least one certificate authority 
filter (309) is between the level of trust of an untrusted 
Certificate Authority and a trusted Certificate Authority 
(level of trust "likely" or "to be verified"), and if the 

25 level of trust assigned to the certificate authority by each 
of the other certificate authority filters (309) corresponds 
to the level of trust of a trusted Certificate Authority, 

• (408) informs the Certificate Locker to let the message 
Certificate in the "frozen zone" in order to prevent 

30 any application from using it. 

• waits for the next request to process. 
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Preferably, a warning message is displayed on the screen of 
the workstation to inform the user that a received message has 
been discarded or that a CA authentication has been requested 
to CA filters Administrators. 



5 CA Filter 

In order to verify whether or not the CA is a trusted CA, the 
Certificate Checker (312) contacts (307) a CA Filter component 
(309) • The CA Filter is comprised within a device (308) . Said 
device (308) is preferably a dedicated and protected device 
10 which is, for instance, a Certificate Authority (CA) internal 
to company network. 

In a preferred embodiment, multiple and independent CA Filters 
are setup within the company network. In this case, the 
Certificate Checker verifies with each CA Filter if the CA is 
15 a trusted CA. The use of multiple CA Filters provides a 
maximum effectiveness to the present invention, in particular 
when a CA Filter becomes corrupted (for instance when a CA 
Filter is attacked) . 



A CA Filter (309) is mainly a central repository comprising a 
20 list of trusted CAs with their associated Certificates. Said 
repository is stored within a CA Filter Table (CAF Table) 
(310) . The list of trusted CAs is periodically maintained, 
typically by a Security Administrator, according to some 
security guidelines specific to the company. For instance: 



25 • The company can accept only a very limited list of trusted 
CAs in order to minimize the security exposure in the event 
a well known CA is attacked and becomes malicious (the less 
trusted CAs, the lower the risk of security breakage is) . 
• Any CA object of an attack, is immediately removed from the 

30 list of trusted CAs. 



The list of trusted CAs may depend on the destination of the 
signed message. For instance, some sensitive organizations 
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within a company (such as the Legal Department) may be allowed 
(by company decision) to receive messages only if these 
messages are signed by some very specific CAs, while another 
organization within the same company may be allowed to receive 
messages signed with a wider list of trusted CAs . In this 
case, the degree of trust of a CA ■ listed in the CAF Table 
depends on the destination of the signed message within the 
company. Optionally, various degrees of trust can be 
associated with each CA. For instance, a CA can be either: 

• "Trusted"; the CA is a trusted CA. The messages signed by 
this CA can be received within the company. 

• "£iJce2jr"; the CA is not a trusted CA but is likely a trusted 
CA (for instance, the administrative process checking the 
seriousness of the CA, is almost complete with success) . In 
this case, messages signed with this CA are allowed or not 
depending on the company security policy. For instance, a 
company which is very strict for security will decide to 
discard messages signed by this CA, while another company 
will allow messages signed by this CA. 

• "t7n trusted"; the CA is not a trusted CA. In this case, all 
messages signed by this CA must be discarded. 

CA Filter Table (CAF Table) 

Figure 5 describes the table used by the CA Filter (309) . Said 
table provides a list of trusted CAs and for each CA, the 
associated Certificate. This table is called CA Filter (CAF 
Table) Table (310). The CA Filter Table (501) (a flat file in 
a preferred embodiment) is typically created by the Security 
Administrator in charge of the device (308) comprising the CA 
Filter component (308). The table is also typically maintained 
and periodically updated by the Security Administrator 
according to the security policy of the company. This table 
comprises for each CA: 

• The CA identifier 
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• The CA Certificate 

• An information which indicates whether the CA is a trusted 



CA or not, 



The CA Filter Table (501) comprises a list of records (502) . 
5 There is one record for each CA, each record comprising the 
following information : 



• (503) CA_Id: this field comprises the identifier of the CA. 
Typically, this is the name of the CA which is defined in 
the Issuer field (102) of the Certificates issued by the CA. 

10 • (504) CAjCertl£lcat&\ this field comprises the Certificate 
of the CA. 

• (505) CA__T2mst^Level_L: this field comprises an information 
indicating the level of trust of the CA. This information 
comprises two information: 

15 • (506) Destination: this field comprises the identifier of 

a user or group of users. For instance this is a range of 
IP addresses. This is an optional information. By 
default, the level of trust specified in the 
CA_Trust_Level field applies to any Destination. 

20 • (507) CA^Trust^Lev&l: this is the level of trust of the 

CA, for the particular "Destination". For instance, the 
CA may be "trusted" for one organization or one activity 
in the company and be "likely" for another organization 
or activity in the company. By default, the 
25 CA_Trust_Level field is set to the value "trusted". Other 

values can possibly be assigned to the CA_Trust_JLevel 
field, for instance: 

• "Likely": the CA is not yet trusted, but is in the 
process to be trusted (for instance, to be trusted, the 

30 CA waits for an administrative approval) . Therefore, in 

some situations, the CA can already be considered as a 
trusted CA. 

• "Untrusted" : the CA is not trusted. 
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• "To be Verified" : the CA is not trusted, but some 
Certificate Checkers (312) have requested the 
Certificate of this CA. The Security Administrator 
wants to verify whether such a CA can be trusted or 
not. The CA_Trust_Level field is updated to "trusted" 
or "untrusted" accordingly. 
By default, CA_Trust_Level_L contains only one 
CA_Trust_Level which is then the level of trust of the CA 
identified by CA_Id. 

Certificate Checker Table (CFC Table) 

Figure 6 describes the table used by the Certificate Checker 
(312) . Said table comprises the identifier of each CA Filter 
holding the list of trusted CAs within the company and their 
associated Certificates. This table is called Certificate 
Checker (CFC Table) Table (313) . The Certificate Checker Table 
(601) (a flat file in a preferred embodiment) is typically 
created by the Network Administrator in charge of the entities 
(for instance all user workstations) comprising a Certificate 
Checker (312) . This table comprises the identifier of each CA 
Filter available for retrieving the Certificate of a specific 
CA. The Certificate Checker Table (601) comprises a list of 
records (602). There is one record for each CA Filter, each 
record comprising the following information: 

• (603) CA_Filter_IcZ: this is the identifier of the device 
(308) comprising the CA Filter. This is for instance the IP 
address of a computer system. 

CA Filter 

According to the present invention, the main purpose of the CA 
Filter (309) is to manage a list of CAs with their associated 
Certificate and level of trust. The CA Filter is accessed each 
time information related to the level of trust of a particular 
CA must be retrieved. Each time the CA Filter receives a 
request for retrieving information related to the level of 
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particular CA, the- following operations are 



retrieving the level of trust associated with the CA from 
the CA Filter Table, Optionally, this step further comprises 
the step of selecting the level of trust from a list, 
according to the destination information sent within the 
request . 

answering the request with the retrieved level of trust 



Typically, the CA Filter is either a dedicated network device 
10 (309) , or an existing network device (for instance an IP 
Router) adapted to provide the Certificate Filter functions. 
However, the CA Filter is preferably a dedicated device which 
is used as an internal CA. 



Figure 7 is a flow chart which refers to the internal logic of 
15 the CA Filter. The CA Filter: 



• (701) : receives a request to verify a CA. Said request for 
CA verification comprises: 

• The type of the request (called "Request_Type") . The 
"Request_Type" field has preferably two values: 

20 • "Verif ication" : the request is a request to retrieve 

the level of trust of a particular CA. 
• xx Full": the request is a request to retrieve the 
Certificate of a particular trusted CA. 

• The CA identifier (called "CA_Identif ier" ) of the 
25 particular CA. 

• Optionally, the identifier (in a field called 
"Msg_Dest") of one or a group of users (for instance 
the IP address of a particular user) . 

• (702) : retrieves all records (502) from the CA Filter Table 
30 (703) . 
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• (703) : checks whether or not a record (502) corresponds to 
the CA identified in the request. This record is the record 
where the CA name or identifier "CA_Id" (503) in the CA 
Filter Table (501) is equal to the "CA_Id" received in the 
5 request. 



If no record is found 

• (705) sends a negative response indicating that the 
level of trust of the CA identified in the "CA_Id" 
field was not found. 



10 If a record is found 

• (706) retrieves the level of trust of the CA. 

The level of trust (in the field called 
"Level_of_Trust") is extracted from the 

"CA_Trust_Level_L" (505) list within the record. 

15 "Level_of_Trust" is the value of the "CA__Trust_Level" 

(507) field associated with the "Destination" field 
which is equal to the "Msg_Dest" information received 
in the request. 

If "Msg__Dest" is empty (this may happen because this is 
20 an optional information) , the "Level_of_Trust" is equal 

by default to the first "CAJTrust_Level" field of "the 
CA_Trust__Level_L" list . 

If the Request has a Request_Type = "Full" 
• (709) sends back a response comprising: 
25 • "Level_of_Trust" 

• "CA Certificate" field of the record 



If the Request has a Request_Type not equal to "Full 
(a Request_Type equal to "Verification") 
• (708) sends back a response comprising: 
30 • "Level of Trust" 
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Then waits for next request to process. 

While the invention has been particularly shown and described 
with reference to a preferred embodiment, it will be 
understood that various changes in form and detail may be made 
5 therein without departing from the spirit, and scope of the 
invention . 
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Claims 

1. A method in a workstation (302) connected to a network 
(314), for filtering certificates issued from one or a 
plurality certificate authorities (CA) , said method comprising 
5 the steps of: 

• receiving a certificate and storing said certificate; 

• preventing the use of said certificate until validation; 

• identifying (402) the certificate authority (CA) (203) that 
has issued the certificate; 

10 • verifying whether or not said identified certificate 
authority (CA) is a trusted certificate authority, said step 
comprising the further steps of: 

• identifying (403) one or a plurality of certificate 
authority filters (CAF) (309) referring to a table (CFC 

15 table) (313) , said table comprising an identification of 

one or a plurality of certifcate authority filters ; 

• sending (405) a request to one or a plurality of said 
identified certificate authority filters (309) ; 

• receiving (406) from each certificate authority filter 
20 (309) a response to said request, said response 

comprising information related to the certificate 
authority that has issued the certificate and depending 
on said information a public key; 

• determining (407) according to said responses whether or 
25 not said certificate authority is a trusted certificate 

authority; 

• validating (410) the certificate if the certificate 
authority (CA) that has issued the the certificate is a 
trusted certificate authority. 



30 



2. The method according to the preceding claim comprising the 
further steps of : 
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• discarding (408) the certificate if one or a plurality of 
responses indicate that the certificate authority (CA) that 
has issued the certificate is not a trusted certificate 
authority; 

5 • optionally sending a warning message to the workstation 
user . 



3. The method according to anyone of the preceding claims 
wherein the step of identifying (402) the certificate 
authority (CA) (203) that has issued the certificate comprises 
10 the further step of: 



• retrieving an identification (102) of the certificate 
authority (CA) (203) from the certificate. 

4. The method according to anyone of the preceding claims 
wherein the step of sending (405) a request to one or a 
15 plurality of said identified certificate authority filters 
(309) , comprises the further step of : 

• including in said request an identification of the 
certificate authority (CA) (203) that has issued the 
certificate 



20 5. The method according to anyone of the preceding claims 

• wherein the response received from each certificate 
authority filter (309) comprises a level of trust assigned 
to the certificate authority, and 



• wherein the step of determining (407) according to the 
25 response whether or not said certificate authority (CA) 

(203) is a trusted certificate authority for said 
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certificate authority filter (309), comprises the further 
steps of: 

• checking whether or not the level of trust assigned by 
each certificate authority filter (309) to the 
5 certificate authority corresponds to the level of trust 

of a trusted certificate authority. 

6. The method according to anyone of the preceding claims 
wherein said step of validating (410) the certificate 
comprises the further steps of: 

10 • comparing the public key comprised in the response received 
from each certificate authority filter; 

• validating the certificate if all received public keys are 
identical 

7. A system (302), preferably a workstation connected to a 
15 network, comprising means adapted for carrying out the method 

according to anyone of the preceding claims. 

8. A computer program comprising instructions adapted for 
carrying out the steps of the method according to anyone of 
claims 1 to 6 when said computer program is executed on a 

20 computer. 

9. A method in a certificate authority filter (309) connected 
to a network (314), for filtering certificates issued from one 
or a plurality certificate authorities (CA) , said method 
comprising the steps of: 

25 • receiving (701) a request comprising an identification of a 
certificate authority (CA) ; 

• identifying the certificate authority (CA) in said request; 
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• identifying (702, 704) in a table (CAF table) (310, 501) the 
certificate authority identified in the request, said table 
comprising: 

• the identification of one or a plurality of certificate 
5 authorities; and 

• a level of trust and a public key associated with each of 
said one or plurality of certificate authorities; 

• determining (706) the level of trust of the identified 
certificate authority (CA) referring to said table; 

10 • retrieving (707) the public key associated with the 
identified certificate authority (CA) refering to said 
table; 

• sending (709) a response to the originator of the request, 
said response comprising the level of trust of the 

15 certificate authority identified in the request and the 

public key associated with said certificate authority. 

10. The method according to the preceding claim wherein said 
request, further comprises an identification of a destination 
entity (302) . 

20 11. The method according to anyone of claims 9 to 10 wherein 
said step of determining (706) the level of trust of the 
identified certificate authority (CA) referring to said table, 
comprises the further steps of: 

• determining (706) the level of trust (507) of the identified 
25 certificate authority (CA) for the destination entity (506) 

identified in the request, said table (310, 501) comprising 

• one or a plurality of certificate authorities (502), 

• for each of said one or plurality of certificate 
authorities (502) , one or a plurality of destination 

30 entities (506), and 

• a level of trust (507) associated with each of said one 
or plurality of certificate authorities (502) and with 
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each of said one or plurality of destination entities 
(506) . 



13. The method according to anyone of claims 9 to 12 wherein 
said certificate authority filter is preferably comprised in a 

5 certificate authority. 

14. The method according to anyone of the claims 9 to 13 
wherein the originator of the request is a system according to 
claim 7. 



15. A certificate authority filter (309) , comprising means 
10 adapted for carrying out the method according to anyone of 
claims 9 to 14. 



16. A computer program comprising instructions adapted for 
carrying out the steps of the method according to anyone of 
claims 9 to 14 when said computer program is executed on a 

15 computer. 

17. A system comprising a system (302) according to claim 7 
connected to one or a plurality of certificate authority 
filters (309) according to claim 15. 
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METHOD AND SYSTEM FOR USING WITH CONFIDENCE 
CERTIFICATES ISSUED FROM CERTIFICATE AUTHORITIES 



Abstract 

The present invention relates to the security of 
5 communications between computer devices, and more particularly 
to a method and system for using, with confidence and trust, 
certificates issued from Certificate Authorities (CA) . The 
present invention discloses a system and method in a 
workstation connected to a network, for filtering certificates 
10 issued from one or a plurality certificate authorities (CA) . 
The method comprises the steps of: 

• receiving a certificate and storing said certificate; 

• preventing the use of said certificate until validation; 

• identifying the certificate authority (CA) that has issued 
15 the certificate; 

• verifying whether or not said identified certificate 
authority (CA) is a trusted certificate authority, said step 
comprising the further steps of: 

• identifying one or a plurality of certificate authority' 
20 filters (CAF) referring to a table (CFC table), said 

table comprising an identification of one or a plurality 
of certifcate authority filters ; 

• sending a request to one or a plurality of said 
identified certificate authority filters; 

25 • receiving from each certificate authority filter a 

response to said request, said response comprising 
information related to the certificate authority that has 
issued the certificate and depending on said information 
a public key; 

30 • determining according to said responses whether or not 

said certificate authority is a trusted certificate 
authority; 
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validating the certificate if the certificate authority (CA) 
that has issued the the certificate is a trusted certificate 
authority. 



Figure 3 
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